Distributed authenticity verification for consumer payment transactions

ABSTRACT

Payment tokens designed for display on a consumer&#39;s mobile device include dynamic trust data (e.g., transaction history and/or token generation date) along with financial account information, enabling merchants to make an informed decision about whether to accept payment without communication with the central processing system, and also protecting the consumer&#39;s account information from theft.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a continuation of and claims priority to and thebenefit of U.S. patent application Ser. No. 13/797,287 (filed on Mar.12, 2013). The foregoing application is incorporated herein by referencein its entirety.

BACKGROUND

It is common practice for consumers to pay a merchant electronically forgoods or services received. Electronic payments are typically made witha token that identifies a source of funding. For example, a credit cardcontaining a magnetic strip is a token. Payment tokens usually containstatic information, such as an account number, identifying a source ofpayment. When a credit card is swiped, the card number is transmitted toa centralized payment processing system. Before authorizing payment, thecentralized payment processing system may verify whether the accountexists and is active, whether the account can fund the transaction, orwhether the transaction may be fraudulent. A physical token such as acredit card cannot be easily modified and, in the event that it is lostor stolen, the consumer must report the lost card and wait for areplacement to be mailed. As a result, systems that allow a consumer topay for a transaction at the point of sale (POS), using a mobile deviceto display a token (usually in the form of a barcode or QR code), arebecoming widely accepted. Similar to credit-card tokens, mobile devicetokens typically contain static information that must be transmitted toa centralized payment processing system for authentication and paymentauthorization.

If the centralized payment-processing system or the merchant systemloses network access (e.g., a network problem, a system power outage, asystem fire, a system bug, or the like), however, the token cannot beused for payment without significant risk of fraud. Some merchants maycopy (e.g., take a credit-card imprint) or otherwise save the consumer'saccount information or token, deliver goods to the consumer, and attemptto process the payment at a later time when the network is restored. Butif the token is a fraud, the merchant will not get paid. In addition,the mere act of copying account information creates a risk of theft forthe owner of the token.

Accordingly, a system that protects both the consumer and the merchantfrom the risk of fraud regardless of network availability is needed.

SUMMARY

The present invention addresses these problems by encrypting a paymenttoken for display on a consumer's mobile device with dynamic trust data(e.g., transaction history and/or token generation date) along with thefinancial account information. This approach not only enables themerchant system to make an informed decision about whether to acceptpayment without communication with the central processing system, butalso protects the consumer's account information from theft.

Accordingly, in one aspect, the invention pertains to a method ofprocessing a transaction among a consumer, a merchant point-of-salesystem and a transaction-processing entity. In representativeembodiments, the method includes generating a token encrypted with dataidentifying a financial account of the consumer and trust data for theconsumer; receiving and storing the token by a device of the consumer;reading and decrypting, by the merchant system, the token uponpresentation thereof by the consumer's device in connection with thetransaction; authorizing, by the merchant system, the transaction basedon (i) successful decryption of the token and (ii) the trust levelwithout communication with the transaction-processing entity; subsequentto authorization of the transaction by the merchant system,communicating, by the merchant to the transaction-processing entity, arecord of the transaction and authorization thereof; and following thecommunication from the merchant system to the transaction-processingentity, completing the authorized transaction by causing funds to betransferred from the consumer's financial account to the merchant. Theauthorized transaction may be completed upon approval by thetransaction-processing entity of a basis for the authorization by themerchant system. Additionally, the approval by the merchant system mayalso be based on a time of generation of the token and a time of thereading.

In various embodiments, the trust data contains at least a tokengeneration time, a transaction history of the consumer, a spending limitof the consumer or, a home region of the consumer. The trust data may bea single trust-factor value. The token may be encrypted using public keycryptography. As an alternative to encryption, the token may be signedwith a digital signature. The token may be displayed as a “QuickResponse” (QR) code on the consumer device, and may be a one-time-usetoken.

In various embodiments, the method may additionally include generatingand storing, on the consumer device, a plurality of tokens. Following atriggering event, such as expiration of a pre-set time period orpresentation of the token, a first token may be marked for deletion anda second token may be marked for display on a subsequent presentation.The presentation of the first token may comprise receiving confirmationfrom the merchant system that the token was received. Additionally, themethod may include generating a token to replace the token marked fordeletion. In various embodiments, the token may not be marked fordeletion until a deletion communication is received from thetransaction-processing entity. Alternatively, following presentation ofa first token, the first token may be marked for deletion and a secondtoken is marked for display after a predetermined time period. Thetokens may be used by removing them from the stack and used tokens arereplaced with new tokens. In various embodiments, the tokens may bestored in a stack for sequential access on a first in, first out basis.Alternatively, the tokens are stored in a stack for sequential access ona first in, last out basis.

In various embodiments, the consumer may be identified prior togenerating the token.

In another aspect, the invention relates to a system for processing atransaction among a consumer, a merchant and a transaction-processingentity. In various embodiments the system includes a token server for(i) generating a token encrypted with data identifying a financialaccount of the consumer and trust data for the consumer, and (ii)communicating the token to a device of the consumer; a point-of-salesystem for reading and decrypting the token upon presentation thereof bythe consumer in connection with the transaction, the point-of-salesystem being configured to authorize the transaction based on (i)successful decryption of the token and (ii) the trust level withoutcommunication with the transaction-processing entity; and atransaction-processing server configured to (i) receive, from thepoint-of-sale system subsequent to transaction authorization, a recordof the transaction and authorization thereof, and (ii) cause completionof the authorized transaction by causing funds to be transferred fromthe consumer's financial account to the merchant. The point-of-salesystem may be configured to authorize the transaction based at least inpart on a time of generation of the token and a time of the reading. Thetoken server may be configured to encrypt the token using private keycryptography.

In various embodiments, the token server may be configured to embed anexpiration time in the generated token. Additionally, the token servermay be configured to embed a creation time in the generated token. Thetoken server may be configured to generate and communicate a series oftokens to the device. In various embodiments, the token server may beconfigured to verify the consumer's identity prior to token generation.

In another aspect, the invention pertains to a method of processing atransaction among a consumer, a merchant point-of-sale system and atransaction-processing entity. In representative embodiments, the methodincludes generating a token with a digital signature, encrypted using aprivate key, with data identifying a financial account of the consumerand trust data for the consumer; receiving and storing the token and thesignature by a device of the consumer; reading the token and decryptingthe signature, by the merchant system, upon presentation of the token bythe consumer's device in connection with the transaction; authorizing,by the merchant system, the transaction based on (i) successfulverification of the signature and (ii) the trust level withoutcommunication with the transaction-processing entity; subsequent toauthorization of the transaction by the merchant system, communicating,by the merchant to the transaction-processing entity, a record of thetransaction and authorization thereof; and following the communicationfrom the merchant system to the transaction-processing entity,completing the authorized transaction by causing funds to be transferredfrom the consumer's financial account to the merchant.

In another aspect, the invention relates to a system for processing atransaction among a consumer, a merchant and a transaction-processingentity. In various embodiments the system includes a token server for(i) generating a token with a digital signature, encrypted using aprivate key, with data identifying a financial account of the consumerand trust data for the consumer, and (ii) communicating the token to adevice of the consumer; a point-of-sale system for reading anddecrypting the signature upon presentation of the token by the consumerin connection with the transaction, the point-of-sale system beingconfigured to authorize the transaction based on (i) successfulverification of the signature and (ii) the trust level withoutcommunication with the transaction-processing entity; and atransaction-processing server configured to (i) receive, from thepoint-of-sale system subsequent to transaction authorization, a recordof the transaction and authorization thereof, and (ii) cause completionof the authorized transaction by causing funds to be transferred fromthe consumer's financial account to the merchant.

As used herein, the term “or” is intended to mean an inclusive “or”rather than an exclusive “or.” That is, unless specified otherwise, orclear from context, “X employs A or B” is intended to mean any of thenatural inclusive permutations. That is, if X employs A; X employs B; orX employs both A and B, then “X employs A or B” is satisfied under anyof the foregoing instances. Moreover, articles “a” and “an” as used inthe subject specification and annexed drawings should generally beconstrued to mean “one or more” unless specified otherwise or clear fromcontext to be directed to a singular form. In addition, the terms like“consumer equipment,” “mobile station,” “mobile,” “communicationdevice,” “access terminal,” “terminal,” “handset,” and similarterminology, refer to a wireless device (e.g., cellular phone, smartphone, computer, PDA, set-top box, Internet Protocol Television (IPTV),electronic gaming device, printer, and so forth) utilized by a consumerof a wireless communication service to receive or convey data, control,voice, video, sound, gaming, or substantially any data-stream orsignaling-stream. The foregoing terms are utilized interchangeably inthe subject specification and related drawings. The terms “component,”“system,” “platform,” “module,” and the like refer broadly to acomputer-related entity or an entity related to an operational machinewith one or more specific functionalities. Such entities can behardware, a combination of hardware and software, software, or softwarein execution. For example, a component may be, but is not limited tobeing, a process running on a processor, a processor, an object, anexecutable, a thread of execution, a program, and/or a computer. By wayof illustration, both an application running on a server and the servercan be a component. One or more components may reside within a processand/or thread of execution and a component may be localized on onecomputer and/or distributed between two or more computers. Also, thesecomponents can execute from various computer readable media havingvarious data structures stored thereon. The components may communicatevia local and/or remote processes such as in accordance with a signalhaving one or more data packets (e.g., data from one componentinteracting with another component in a local system, distributedsystem, and/or across a network such as the Internet with other systemsvia the signal).

BRIEF DESCRIPTION OF THE DRAWINGS

In the drawings, like reference characters generally refer to the sameparts throughout the different views. Also, the drawings are notnecessarily to scale, with an emphasis instead generally being placedupon illustrating the principles of the invention. In the followingdescription, various embodiments of the present invention are describedwith reference to the following drawings, in which:

FIG. 1 is a block diagram of an exemplary network in accordance with anembodiment of the invention;

FIGS. 2A, 2B, and 2C are block diagrams of an exemplary consumer device,token-generation server, and merchant system, respectively, inaccordance with an embodiment of the invention;

FIG. 3 depicts an exemplary system for performing secure paymenttransactions in accordance with an embodiment of the invention; and

FIGS. 4A, 4B, and 4C are flowcharts illustrating performance of securepayment transactions in accordance with an embodiment of the invention.

DETAILED DESCRIPTION

Refer first to FIG. 1, which depicts an exemplary mobile-paymenttransaction network 100 including a consumer device (e.g., a mobiledevice) 102 linked to a network 104 (e.g., a cellular telephone network,the Internet, or any wide-area network or combination of networkscapable of supporting point-to-point data transfer and communication)that supports wired, wireless, or any two-way communication. The network104 connects various devices, including a token-generation server 106,one or more merchant systems (e.g., POS terminals) 108, and a paymentprocessor 110 utilizing, again, wired, wireless, or any two-waycommunications. The token-generation server 106 is responsible forgenerating encrypted, unique payment tokens associated with theconsumer. Each merchant system 108 may be associated with a merchant whooffers goods or services for sale to the consumer possessing the mobiledevice 102. In one embodiment, the merchant system 108 is a POS system(e.g., an electronic cash register) that connects to a code reader orscanner (hereafter “reader”) 112. The reader 112 may be capable ofreading and/or decoding a payment token, in the form of, for example, abarcode, a radio frequency identification (RFID) code, or a QR code,and/or receiving signals, such as NFC signals, acoustic signals, orinfrared signals. In addition, the reader 112 may be mobile orphysically associated with the merchant system 108. The merchant system108 may be responsible for decrypting the decoded payment tokeninformation and authenticating the payment transaction based oninformation provided therein. The payment processor 110 may beresponsible for actually performing the payment transaction and, in somecases, for decrypting the payment token. For example, a so-called“direct” payment processor represents the financial-processing backendprovider to credit-card issuers and payment services such as PAYPAL. An“indirect” payment processor is an independent entity processingtransactions for multiple payment services and maintains its own recordsand data. The payment processor 110 may also be configured to decryptand authenticate the token as a second verification layer.

The mobile device 102 acts as a gateway for transmitting the consumer'sdata to the network 104. The mobile device 102 can support multiplecommunication channels for exchanging multimedia and other data with theserver 106 and other devices using a Wi-Fi LAN (e.g., IEEE 802.11standard) for Internet access, a short-range Bluetooth wirelessconnection for point-to-point access, and/or an NFC channel forclose-proximity access. Referring to FIG. 2A, in various embodiments,the mobile device 102 includes a conventional display screen 202, a userinterface 204, a processor 206, a transceiver 208, and a memory 210. Thetransceiver 208 may be a conventional component (e.g., a networkinterface or transceiver) designed to provide communications with anetwork, such as the Internet and/or any other land-based or wirelesstelecommunications network or system, and, through the network, with thetoken-generation server 106. The memory 210 includes an operating system(OS) 212, such as GOOGLE ANDROID, NOKIA SYMBIAN, BLACKBERRY RIM orMICROSOFT WINDOWS MOBILE, and a code process 214 that implements thedevice-side functions as further described below. Additionaltransactional information may be embedded in the code process 212 fortransmission through the network 104 for later processing on a back-endserver (e.g., the token-generation server 106). As used herein, the term“mobile device” used for transacting a mobile payment refers to a “smartphone” or tablet with advanced computing ability that, generally,facilitates bi-directional communication and data transfer using amobile telecommunication network, and is capable of executing locallystored applications and/or payment transactions. Mobile devices include,for example, IPHONES (available from Apple Inc., Cupertino, Calif.),BLACKBERRY devices (available from Research in Motion, Waterloo,Ontario, Canada), or any smart phones equipped with the ANDROID platform(available from Google Inc., Mountain View, Calif.), tablets, such asthe IPAD and KINDLE FIRE, and personal digital assistants (PDAs). Thememory 210 may include computer storage media in the form of volatileand/or nonvolatile memory such as read only memory (ROM) and randomaccess memory (RAM). A basic input/output system (BIOS), containing thebasic routines that help to transfer information between elements, suchas during start-up, is typically stored in ROM. RAM typically containsdata and/or program modules that are immediately accessible to and/orpresently being operated on by processing unit.

The token-generation server 106 is a trusted system that generatesencrypted payment tokens. In response to requests made by a registereduser via the consumer device 102, the server 106 generates tokens andtransmits them to the consumer device 102 for presentation to complete atransaction. Referring to FIG. 2B, in various embodiments, thetoken-generation server 106 includes a processor 222 and a memory 224,which may include volatile and non-volatile portions. The memory 224contains instructions, conceptually illustrated as a group of modules,that control the operation of the processor 222 and its interaction withhardware components. An operating system 226 directs the execution oflow-level, basic system functions such as memory allocation, filemanagement and operation of mass storage devices. At a higher level, alook-up module 228, a PKI module 230, a web server block 234, and acommunication module 236 perform the basis system functions described ingreater detail below. The communication module 234 may be a conventionalcomponent (e.g., a network interface or transceiver) designed to providecommunications with a network, such as the Internet and/or any otherland-based or wireless telecommunications network or system, and,through the network, with the mobile device 102, the merchant system108, and the payment processor 110. The web-server block 236 enablesweb-based communication with the mobile device 102, and can be aconventional web-server application executed by the processor 222.

A consumer database 240 may reside in a storage device 238 and/or anexternal mass-storage device 242 accessible to the token-generationserver 106; the consumer database 240 stores, for example, a recordassociated with each registered consumer, or device, with associatedtrust data (e.g., transactional data). The database 240 is responsive toqueries from lookup module 228.

In operation, the user operates an executable, interactive application(an “app”) on the mobile device 102 identifies himself to the server106, e.g., using a password or other strong form of authentication. Thelook-up module 228 obtains the user's account records from the database240 and, using the PKI module 230, generates an encrypted token for thatuser using a private key. The encrypted token contains information touniquely identify the token or the user of the token, as well as trustdata from the user's database record. Trust data may also reflect thetime the token was generated, since more recently created tokens areconsidered more trustworthy (since the likelihood of fraudulent accessor use increases over time). In general, trust data reflects aprobability that the payment processor 110 will ultimately authorize thedesired payment on the user's behalf. For example, the trust data mayspecify how many transactions the consumer has processed in the past (insome embodiments, more recent transactions may receive a greater trustweight), the spending limit of the consumer, the home region of theconsumer, the transaction history of the consumer (in some embodiments,transactions at merchants where the consumer has transacted previouslymay receive a greater trust weight), the age of the consumer's account(which may be correlated with the user's transaction history, but is adistinct piece of information which is much smaller to store), and otherdemographic information. Additional trust factors can include trustlevels of other individuals with whom the user is somehow associated(e.g., social network “friends”), as well as trust levels associatedwith those individuals' friends and the number of funding sources theuser has. For example, a user with only a single funding source may be ahigher risk than a user with multiple funding sources (e.g., one creditcard or bank account on file, versus many different accounts on file).This may also be based on the institutions in which the accounts areheld, as it is less likely for a user to close accounts across differentinstitutions simultaneously. In some embodiments, an aggregated“trust-factor” value is calculated that collapses all of these variousmetrics into a single value to be included in the token. Thetrust-factor value may be numeric or may simply be a coarse level, e.g.,low, medium, or high.

Trust data may be updated when the registered user initiates orcompletes a new transaction, e.g., when the server 106 receives a recordof a new transaction from the payment processor 110 via thecommunication module 234. In another embodiment, the trust data isupdated periodically in a predetermined time period. For example, thetrust data may be updated at a set time each day based on transactionsthat the user has completed within the previous 24 hours. The trust datamay also be updated continuously based on patterns from all transactionsprocessed, including transactions not involving the particular user.Similarly, the trust data may be updated continuously based on the trustfactor of that person's social network “friends.”

The server 106 transmits the generated token back to the mobile device102 via the communication module 234. As is well understood in the art,the token, encrypted using the private key, may be decrypted using apublic key; the latter is made available to merchant systems 108 to usein the course of transactions in accordance herewith. In one embodiment,the private key and associated public key (the private/public key pair)are reset periodically (e.g., in a predetermined period of time) forsecurity purposes; the public key is communicated, via communicationmodule 234, to the merchant system 108 upon every reset. In anotherembodiment, the private/public key pair is unchangeable. The token maybe an authentication that is read directly by the merchant system 108using, for example, NFC; may encode an optically readable “mature code”(e.g., a QR code or a bar code) that is displayed on the screen of themobile device 102; or may be a “seed code” from which the mobile device106 (via the app) can generate a mature code later.

Referring to FIG. 2C, in various embodiments, the merchant system 108includes a processor 252, a memory 254, an operating system 256, adecision module 258, a decryption module 260, a web server block 264, acommunication module 266, and a storage device 268. As described above,the various functional modules are typically implemented as storedinstructions that operate as running processes via the processor 252.The merchant system 108 may be connected to or include the reader 112,which is capable of reading payment tokens according to any suitablemodality (optical, NFC, etc.) from a consumer's mobile device 102. Thedecryption module 260 stores the public key and decrypts the tokenobtained by the reader 112. If decryption is successful, the decisionmodule 258 may, in some embodiments, further authenticate the token orthe consumer if decryption is successful (e.g., by requesting a passwordor biometric indicium, such as a fingerprint, from the consumer). Ininstances where the merchant system 108 does not or presently cannotcommunicate with the payment processor 110, the decision module 258decides, based on the decrypted trust data, whether to authorize thetransaction as further described below. Accordingly, the merchant system108 does not require continuous network access in order to authorizetransactions. The transaction may be authorized based on the trust dataand transactional information saved in storage device 268 for latertransmission through the network 104 for processing on a back-end server(e.g., the payment processor 110).

As illustrated in FIG. 3, payment transactions in accordance herewithmay involve different stages that need not take place in tandem or atspecific times, but instead may occur whenever a network connection canbe established: a token-generation stage 302, a payment-initiation stage304, a payment-authorization stage 306, a funds-transfer stage 308, anda database-update stage 310. For example, the payment initiation stage304 does not require a network connection when the encrypted token isread from the mobile device 102 by a POS merchant system 108. Thevarious stages are described in further detail below.

A representative method 400 for safely transacting a payment withoutcontinuous network access in accordance with embodiments of the currentinvention is shown in FIGS. 4A, 4B, and 4C (with additional reference toFIGS. 1 and 2A-2C). Assuming the consumer is registered with thetoken-generation server 106, the consumer, or an application acting onbehalf of the consumer, can log in to the server 106 to retrieve apayment token. For example, the consumer may download an app onto hermobile device 102 (step 402); the app, when executed on the mobiledevice 102, communicates with the token-generation server 106 and allowsthe user to log in by supplying a proof of identify, such as ausername/password pair (step 404)—either to the app, which thentransmits the log-in information to the server 106, or to the server 106directly via, for example, a web session—and request a token. Thisrequest is transmitted to the token-generation server 106 (step 406).The identifying information is verified (step 408), once again either bythe app or by the token-generation server 106, and the look-up module228 of the token-generation server 106 looks up the consumer's accountdata stored in database 240 (step 410) and generates a token for theconsumer. The token contains data that identifies the consumer and/orthe token as well as trust data for the consumer. The token may containactual financial account information of the consumer or may insteadcontain information (such as an email address, telephone number, orrandom unique data) that can be mapped to the consumer's account by thepayment processor 110. Before being sent, the token is encrypted usingthe private key (step 414). The encrypted token is then transmitted tothe mobile device 102 (step 416). Although the discussion herein focuseson a private/public key pair method of encryption for purposes ofillustration, the present invention may be implemented using anyasymmetric encryption method in which a secret key is known only to thetoken-generation server 106. In other embodiments, the private key maybe used to digitally sign the token and successful verification of thesignature proves the token's authenticity. Digital signatures utilizethe public key infrastructure to ensure authenticity (i.e., that no onehas tampered with the token in transit and that the token was indeedgenerated by the token-generation server 106.)

The client app running on the mobile device 102 receives and stores theencrypted token (step 418). The token-generation process may take placeat any time after a consumer registers an account. The token may bedelivered to the mobile device 102 at any time a network connection canbe established. Generation of the token and delivery of the token mayoccur as two separate steps and may not happen at the same time. Thedevice 102 need not be continuously connected to network 104 andsporadic connectivity is sufficient to gain the benefits of the presentinvention. In addition, to reduce the risk of tokens being stolen, thetoken can be rotated. For example, the client app may be configured tocheck for network connectivity after a period of time, corresponding tothe desired lifetime of a token, has elapsed since the token wasreceived. If network connectivity is unavailable, the client appperiodically checks until it detects a network connection. The clientapp may poll for connectivity, or the app may asynchronously monitor forconnectivity changes. For example, the operating system of the mobiledevice 102 may have facilities to notify apps asynchronously whennetwork connectivity returns. The app may also be programmed wait for atriggering event before communicating with the server. For example, thistriggering event may be in the form of the user opening the app, theuser clicking a button to refresh his token, or other triggers asdetermined by the app's programming. If two-way communication betweenthe app and the merchant system 108 is possible, the app may rotate thetoken after communicating the previous token to the merchant system 108.At this point, without the involvement of the consumer, the app causesthe mobile device 102 to communicate with the token-generation server106 to obtain a replacement token. In some embodiments, the apppassively monitors for other network traffic on the device prior tocommunicating with the token-generation server 106 in order to optimizepower consumption. When the new token is received, the app causes theold one to be invalidated (so that the consumer uses only the newesttoken in a transaction). Alternatively, the rotation of tokens may beinitiated by the payment processor 110. The payment processor 110 maysend a “push notification” message to the application, eitherperiodically or after a triggering event. For example, the app maydisplay a token but not know when that token has been successfully usedto complete a transaction. When a transaction has been completed, thepayment processor 110 may therefore send a push notification to thedevice to rotate the token. In accordance with this approach, the tokenmay be contained in the push notification or, instead, the pushnotification may simply be a “tickle” to cause the mobile device 102 toinitiate a request to obtain a new token. If the mobile device 102 isoffline when the push notification is sent, delivery of the pushnotification may be queued for delivery once the mobile device 102 comesonline again. The process of networked code rotation is far more securethan simple static tokens.

Alternatively, in response to a token request, the token-generationserver 106 may generate and deliver an encrypted, ordered stack—or“quiver”—of tokens for secure storage in the mobile device 102. Wheneverthe consumer displays a token on the mobile device 102 (even if apayment transaction is not initiated), it is locally marked as displayedand the next token in the stack is marked for display. This processrepeats each time a token is displayed. In some embodiments, each time atoken is displayed, the app causes the mobile device 102 to attempt toestablish a network connection and, when the connection is established,commands the token-generation server 106 to mark the current token(i.e., the one on display) code for invalidation after a short period oftime (e.g., in 60 minutes) and to invalidate all tokens preceding it inthe stack (in case some had been displayed without a networkconnection). In this way, the current token—which is assumed to havebeen displayed because a transaction is imminent—is invalidated within areasonable time to prevent fraud, since a token is at particular riskfor fraudulent acquisition and use when displayed. The token-generationserver 106 may generate and transmit to the mobile device 102 enough newtokens to “refill” the quiver; the new tokens may be stored at the backend of the quiver so that older tokens are used on a first in, first out(FIFO) basis. FIFO operation ensures that the consumer always has newertokens on hand. Alternatively, the new tokens may be stored at the frontend of the quiver for last in, first out (LIFO) operation. While FIFO ispreferred for extended periods of offline access, LIFO is generallybetter for security: newer tokens may have newer fraud informationembedded in them, which benefits the payment network if they are usedfirst. Since most devices tend to establish a network connection on eachtransaction, a reasonable quiver size is 30 tokens, which minimizes thelikelihood of running out of tokens from the quiver. However, if alltokens in the quiver have been displayed without a network connectionhaving been established, the last token is not marked as invalid and themobile device 102 continues to display it. In some embodiments, eachtoken in a quiver is given a sequence number (e.g., the first token issequence 1, the last token is sequence 30). This sequence number may beembedded in the token itself, acting as a form of trust data. If themobile device 102 goes a long period of time without connecting to thetoken-generation server 106, the last token in the quiver may be usedfor a long period of time. In various embodiments, the merchant system108 is configured to reject the last token in a quiver when the mobiledevices are operating in distributed mode and are not able tocommunicate with the payment processing system (e.g., the network isdown). In various embodiments, each token in the quiver has a differentvalidity period embedded in its trust data, and not all of the tokens inthe quiver are valid simultaneously. This reduces the likelihood thatany given token in the quiver can be stolen and used fraudulently.

A payment transaction is initiated when the consumer presents a token(e.g., in the form of a QR code) stored in the mobile device 102 to themerchant system 108 (step 420). The merchant system 108 may scan thecode using the reader 112 (step 422), and thereupon decrypts the tokenusing the public key (step 424). Any token that unsuccessfully decryptsis either fraudulent or corrupted, and the transaction is denied (step426). Any token that successfully decrypts is guaranteed to have beencreated with private key, and is assumed to have come from thetoken-generation server 106. The merchant system 108 may then attempt totransmit the token along with information about the transaction (theamount to be paid, in particular) and the merchant's own identity to thepayment processor 110, and await approval or denial. If a networkconnection cannot be established, however, the merchant system 108 canitself approve the transaction based on the trust data in the tokenusing the decision module 258 (step 428). Although this does notguarantee that the payment processor 110 will ultimately authorize thetransaction, if the token decrypts successfully and was generated withina certain amount of time, and the trust data is satisfactory, the riskmay be acceptable to the merchant.

The criteria applied in evaluating the trust data may be universalacross the system 100 or may be specific to particular merchant systems108. For example, a merchant may choose only to accept tokens fromconsumers whose home region is within a set distance of the POS; tokensfrom consumers who have transacted with the merchant previously; tokensthat have been generated within a set time period; and/or trust datareflecting a transaction history success rate above a thresholdpercentage or number. In the latter case, the transaction history may beweighted in favor of more recent transactions in determining whether thethreshold acceptability level is reached. The threshold acceptabilitylevel may vary with the amount of the transaction, and differentcriteria may receive different weights that themselves vary with thetransaction amount. The trust criteria may be selected and combined inaccordance with the priorities and preferences of the merchant andprogrammed into the decision module 258, which scores each transactionaccordingly. It should be emphasized that trust criteria can include anyfactors relevant to a risk score, e.g., the location of the merchantscored against local aggregated crime statistics from public databases.

If the criteria are satisfied, the merchant system 108 authorizes thetransaction (step 430) and communicates the authorization along with theencrypted token and information about the transaction and the merchant'sown identity to the payment processor 110 when a network connection isavailable (step 432); assuming the consumer's financial account is ingood standing, the payment processor 110 will transfer funds to themerchant. Until a network connection can be established, the token andtransaction information are saved to the local storage 268 in themerchant system 108 for transmission when network connectivity isavailable (step 434).

A middle ground can be established between autonomous approval by themerchant system 108 and connectivity to the payment processor 110. Insome embodiments, an “agent” of the payment processor 110—i.e., aprogram supplied by the payment processor 110 and executing as a runningprocess on the merchant system 108—provides the approval based on thetrust data and the token. In other words, the approval criteria aresupplied by the payment processor, not the merchant, so that upontransaction approval by the agent, the merchant is guaranteed to receivepayment from the payment processor 110. Particularly if the agent issupplied as an executable file, the criteria utilized by the paymentprocessor 110 may be proprietary—i.e., hidden from merchants or otherusers of the executable file. Following approval, the agent causestransaction data to be stored locally and sent to the payment processor110 when network connectivity is available. The agent may be supplied tothe merchant as a secure (hidden) executable file or, in someembodiments, as a separate physical component (e.g., a dongle) withsecurity features that prevent unauthorized access and tampering. Inother embodiments, the agent may be a proxy for a payment processor thatsits within the merchant's network. For example, consider a largemerchant or a grocery store chain where each transaction may go throughan internal network of the merchant, which connects to the internalpayment processor. In some embodiments, the payment may be sent to an“agent” which is a separate server (or software on an existing serverowned by the merchant), which handles the communication with the actualpayment processor 110. If the actual payment processor 110 isunavailable, this agent may act on behalf of the payment processor 110to approve the transaction based on the encrypted information includedin the payment token. This agent would the store the transaction andforward it once the payment processor 110 becomes available again. Whileseveral inventive embodiments have been described and illustratedherein, those of ordinary skill in the art will readily envision avariety of other means and/or structures for performing the functionand/or obtaining the results and/or one or more of the advantagesdescribed herein, and each of such variations and/or modifications isdeemed to be within the scope of the inventive embodiments describedherein. For example, each of the processors described herein may be ageneral-purpose computer, but alternatively may be a CSIC(consumer-specific integrated circuit), ASIC (application-specificintegrated circuit), a logic circuit, a digital signal processor, aprogrammable logic device, such as an FPGA (field-programmable gatearray), PLD (programmable logic device), PLA (programmable logic array),RFID processor, smart chip, or any other device or arrangement ofdevices that is capable of implementing the steps of the processes ofthe invention.

Various implementations of the systems and techniques described here canbe realized in digital electronic circuitry, integrated circuitry,specially designed ASICs (application specific integrated circuits),computer hardware, firmware, software, and/or combinations thereof.These various implementations can include implementation in one or morecomputer programs that are executable and/or interpretable on aprogrammable system including at least one programmable processor, whichmay be special or general purpose, coupled to receive data andinstructions from, and to transmit data and instructions to, a storagesystem, at least one input device, and at least one output device.

The various modules and apps described herein can include machineinstructions for a programmable processor, and can be implemented in ahigh-level procedural and/or object-oriented programming language,and/or in assembly/machine language. As used herein, the terms“machine-readable medium” “computer-readable medium” refers to anycomputer program product, apparatus and/or device (e.g., magnetic discs,optical disks, memory, Programmable Logic Devices (PLDs)) used toprovide machine instructions and/or data to a programmable processor,including a machine-readable medium that receives machine instructionsas a machine-readable signal. The term “machine-readable signal” refersto any signal used to provide machine instructions and/or data to aprogrammable processor.

The terms and expressions employed herein are used as terms andexpressions of description and not of limitation, and there is nointention, in the use of such terms and expressions, of excluding anyequivalents of the features shown and described or portions thereof. Inaddition, having described certain embodiments of the invention, it willbe apparent to those of ordinary skill in the art that other embodimentsincorporating the concepts disclosed herein may be used withoutdeparting from the spirit and scope of the invention. Accordingly, thedescribed embodiments are to be considered in all respects as onlyillustrative and not restrictive.

What is claimed is:
 1. A method of processing a transaction among aconsumer, a merchant point-of-sale system and a transaction-processingentity, the method comprising: generating a token encrypted with dataidentifying a financial account of the consumer and trust data for theconsumer; receiving and storing the token by a device of the consumer;reading and decrypting, by the merchant system, the token uponpresentation thereof by the consumer's device in connection with thetransaction; authorizing, by the merchant system, the transaction basedon (i) successful decryption of the token and (ii) the trust levelwithout communication with the transaction-processing entity; subsequentto authorization of the transaction by the merchant system,communicating, by the merchant to the transaction-processing entity, arecord of the transaction and authorization thereof; and following thecommunication from the merchant system to the transaction-processingentity, completing the authorized transaction by causing funds to betransferred from the consumer's financial account to the merchant. 2.The method of claim 1, wherein the authorized transaction is completedupon approval by the transaction-processing entity of a basis for theauthorization by the merchant system.
 3. The method of claim 1, whereinapproval by the merchant system is also based on a time of generation ofthe token and a time of the reading.
 4. The method of claim 1, whereinthe trust data contains at least one of (i) a token generation time,(ii) a transaction history of the consumer, (iii) a spending limit ofthe consumer or (iv) a home region of the consumer.
 5. The method ofclaim 1, wherein the trust data is a single trust-factor value.
 6. Themethod of claim 1, wherein the token is encrypted using public keycryptography.
 7. The method of claim 1, wherein the token is displayedas a QR code on the consumer device.
 8. The method of claim 1, whereinthe token is a one-time-use token.
 9. The method of claim 1, furthercomprising generating and storing, on the consumer device, a pluralityof tokens.
 10. The method of claim 9, wherein following presentation ofa first token, the first token is marked for deletion and a second tokenis marked for display on a subsequent presentation.
 11. The method ofclaim 10, wherein presentation of the first token comprises receivingconfirmation from the merchant system that the token was received. 12.The method of claim 10, wherein the token is not marked for deletionuntil a deletion communication is received from thetransaction-processing entity.
 13. The method of claim 9, whereinfollowing presentation of a first token, the first token is marked fordeletion and a second token is marked for display after a predeterminedtime period.
 14. The method of claim 1, further comprising marking atoken for deletion and generating a token to replace the token markedfor deletion.
 15. The method of claim 1, wherein the tokens are storedin a stack for sequential access on a first in, first out basis.
 16. Themethod of claim 1, wherein the tokens are stored in a stack forsequential access on a first in, last out basis.
 17. The method of claim1, further comprising identifying the consumer prior to generating thetoken.
 18. A system for processing a transaction among a consumer, amerchant and a transaction-processing entity, the system comprising: atoken server for (i) generating a token encrypted with data identifyinga financial account of the consumer and trust data for the consumer, and(ii) communicating the token to a device of the consumer; apoint-of-sale system for reading and decrypting the token uponpresentation thereof by the consumer in connection with the transaction,the point-of-sale system being configured to authorize the transactionbased on (i) successful decryption of the token and (ii) the trust levelwithout communication with the transaction-processing entity; and atransaction-processing server configured to (i) receive, from thepoint-of-sale system subsequent to transaction authorization, a recordof the transaction and authorization thereof, and (ii) cause completionof the authorized transaction by causing funds to be transferred fromthe consumer's financial account to the merchant.
 19. The system ofclaim 18, wherein the point-of-sale system is configured to authorizethe transaction based at least in part on a time of generation of thetoken and a time of the reading.
 20. The system of claim 18, wherein thetoken server is configured to encrypt the token using private keycryptography.
 21. The system of claim 18, wherein the token server isconfigured to embed an expiration time in the generated token.
 22. Thesystem of claim 18, wherein the token server is configured to embed acreation time in the generated token.
 23. The system of claim 18,wherein the token server is configured to generate and communicate aseries of tokens to the device.
 24. The system of claim 18, wherein thetoken server is configured to verify the consumer's identity prior totoken generation.
 25. A method of processing a transaction among aconsumer, a merchant point-of-sale system and a transaction-processingentity, the method comprising: generating a token with a digitalsignature, encrypted using a private key, with data identifying afinancial account of the consumer and trust data for the consumer;receiving and storing the token and the signature by a device of theconsumer; reading the token and decrypting the signature, by themerchant system, upon presentation of the token by the consumer's devicein connection with the transaction; authorizing, by the merchant system,the transaction based on (i) successful verification of the signatureand (ii) the trust level without communication with thetransaction-processing entity; subsequent to authorization of thetransaction by the merchant system, communicating, by the merchant tothe transaction-processing entity, a record of the transaction andauthorization thereof; and following the communication from the merchantsystem to the transaction-processing entity, completing the authorizedtransaction by causing funds to be transferred from the consumer'sfinancial account to the merchant.
 26. A system for processing atransaction among a consumer, a merchant and a transaction-processingentity, the system comprising: a token server for (i) generating a tokenwith a digital signature, encrypted using a private key, with dataidentifying a financial account of the consumer and trust data for theconsumer, and (ii) communicating the token to a device of the consumer;a point-of-sale system for reading and decrypting the signature uponpresentation of the token by the consumer in connection with thetransaction, the point-of-sale system being configured to authorize thetransaction based on (i) successful verification of the signature and(ii) the trust level without communication with thetransaction-processing entity; and a transaction-processing serverconfigured to (i) receive, from the point-of-sale system subsequent totransaction authorization, a record of the transaction and authorizationthereof, and (ii) cause completion of the authorized transaction bycausing funds to be transferred from the consumer's financial account tothe merchant.